home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / ODF Observations < prev    next >
Encoding:
Internet Message Format  |  1996-07-10  |  1.8 KB  |  [TEXT/ttxt]
  1. Subject:     ODF Observations
  2. Sent:        7/10/96 3:47 AM
  3. Received:    7/10/96 8:46 AM
  4. From:        Hewitt-Jon, MSMAIL.HEWITTJ@TSOD.LMIG.COM
  5. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  6.  
  7.  
  8.  
  9. Hi,
  10.  
  11. I just started working on my first ODF part.  I have a couple observations and
  12. questions I was hoping to get comments on:
  13.  
  14. o My part has a lot of FW_CEditView's. It seemed rather difficult to get the
  15. FW_CEditView's to reflect my part's contents and vice versa.  For example, when
  16. I have multiple frames, I want the changes made to a FW_CEditView in one frame
  17. to be immediately reflected in the other frames.  The default implementation,
  18. i.e. the implementation based on the Hello part, just forced a redraw which
  19. wouldn't do anything to propagate the newly typed text to the corresponding
  20. FW_CEditView's.  My solution was to use the notification subsystem to notify the
  21. frames to update the FW_CEditView's.  Is there a more general way to synchronize
  22. frames and the content?
  23.  
  24. o More notification classes would be useful, i.e. FW_CBecameTargetNotification,
  25. FW_CResignedTargetNotification, FW_CEditViewChangedNotification, etc.
  26.  
  27. o I hate short file names. Alas, the cost of cross-platform code.
  28.  
  29. o When is ODF 2 scheduled for release?
  30.  
  31. o It seems like it would be useful to be able to copy and assign content
  32. objects.  For example, if you want to be able to undo a drop of a part of the
  33. same type, a command class could just retain a copy of the content as the saved
  34. data.  FW_Content lacks an explicit copy constructor and assignment operator.
  35. The compiler generated versions look safe to use for the current class but that
  36. is no guarantee that they will remain safe. Does it make sense to add an
  37. explicit copy constructor and assignment operator?  Or should I use a
  38. stream/archiving to duplicate the content's data?
  39.  
  40.  
  41. Jon Hewitt
  42. MSMAIL.HEWITTJ@TSOD.LMIG.COM
  43.  
  44.